…mat/typo

PR #1588 CI failures:
- Force-override mode (VP_FORCE_MIGRATE=1, set by test-vp-create.yml and
  ecosystem-ci) now re-pins any pre-existing vite-plus range to the local
  tgz path in monorepo workspace packages. Without this, pnpm reads the
  published vite-plus@0.1.21 metadata to resolve transitive deps including
  @voidzero-dev/vite-plus-test@0.1.21, which shadowed upstream vitest@4.1.5
  at runtime and broke vp create monorepo tests.
- typos CI: rename yarn-PnP to yarn Plug'n'Play (Pn→On false positive).
- vp check: format packages/cli/build.ts shim-generation block.
- Rename __dirname in install-failure-guard.spec.ts to satisfy
  eslint(no-underscore-dangle).

…r migration

The migration step intentionally rewrites overrides/catalogs/deps so the
existing lockfile is guaranteed to be stale. pnpm and yarn default to
frozen-lockfile mode under CI, so they refuse the reinstall with
ERR_PNPM_LOCKFILE_CONFIG_MISMATCH and the new handleInstallResult enforcement
propagates that failure as a non-zero exit. Add --no-frozen-lockfile alongside
the existing --force for npm/bun, applied to both the post-migration reinstall
and the ESLint/Prettier early-return reinstall.

…r types through vite-plus, prune monorepo aliases

Three independent fixes for E2E failures introduced by the vite-plus-test → upstream-vitest refactor:

1. Stop rewriting `declare module 'vitest'` (and subpaths/@vitest variants).
   The `vite-plus/test*` shims re-export upstream `vitest*`, so the type identity
   is upstream. Augmenting `'vite-plus/test'` only augments the shim and never
   merges into the upstream types the user actually sees through `import { expect }
   from 'vite-plus/test'`. Import rewrites stay; declare-module rewrites are dropped.

2. Inline-copy upstream `@vitest/browser-*` d.ts content into the test shims and
   rewrite `vitest/node`/`vitest/browser`/`@vitest/browser*` bare specifiers to
   relative paths inside the `dist/test/` tree. Without this, pnpm splits
   `@vitest/browser-playwright` and `vitest` across different peer-dep edges,
   creating two `BrowserProvider` type identities — and `provider: playwright()`
   fails the user's vite.config typecheck.

3. Add the same `pruneLegacyWrapperAliases` calls to `rewriteRootWorkspacePackageJson`
   that `rewriteStandaloneProject` already had. Monorepo migrations were leaving
   stale `npm:@voidzero-dev/vite-plus-test@*` aliases in root resolutions /
   overrides / pnpm.overrides, causing pnpm to install the deleted wrapper.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

…talls

vitest@4.1.5 declares a `vite^6/^7/^8` peer dep. When the user's project
overrides `vite` to `@voidzero-dev/vite-plus-core` (version 0.0.0 in dev
and 0.1.21 on npm — neither matches), bun aborts with:
  error: vite@^6.0.0 || ^7.0.0 || ^8.0.0 failed to resolve

pnpm/yarn/npm tolerate this redirect; bun does not, and offers no
`peerDependencyRules`-style escape hatch — only `[install] peer = false`
in `bunfig.toml`. vite-plus already provides the vite surface the user
needs, so disabling bun's auto-install of *missing* peers is safe here:
the redirected vite is the only one that ever fails, and other vitest
peers (jsdom, happy-dom, @vitest/*, etc.) are upstream-optional and
either pulled in transitively or user-installed.

`ensureBunfigPeerSuppression` writes/merges `bunfig.toml` whenever the
migrator touches a bun project — both the monorepo path (via
`rewriteBunCatalog`) and the standalone path (in
`rewriteStandaloneProject`'s post-package.json branch). Honors any
pre-existing `peer =` setting so a user who deliberately set `peer = true`
keeps it.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

… behavior

Earlier drafts of this branch claimed the migrator stopped rewriting `vitest`
runtime imports and that the browser-provider subpaths were no longer
re-exported. That landed in docs/guide/migrate.md, rfcs/migration-command.md,
and packages/cli/BUNDLING.md, but the implementation kept the forward rewrites
(`vitest` → `vite-plus/test`, `@vitest/browser*` → `vite-plus/test/browser*`)
and added the inlined-d.ts shim infrastructure that *does* re-export every
provider subpath under both `./test/<pkg>` and `./test/browser/providers/<short>`.

The only thing actually preserved is `declare module 'vitest'` / `declare
module '@vitest/browser*'` — those have to target the upstream module identity
to merge into the types `vite-plus/test*` re-exports.

This commit restores the migrate guide's "import { vi } from 'vite-plus/test'"
example, restores the full rewrite-rule list in the migration-command RFC,
fixes the bundling doc's "provider subpaths are not re-exported" claim, and
adds a short subsection explaining why the provider d.ts shims are inlined
instead of bare re-exports (the pnpm-edge type-identity split that would
otherwise break user `provider: playwright()` typechecks).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

…ng during pack

The previous masquerade approach renamed packages/core/package.json
between two pnpm pack calls. Even with the name restored before packing
the CLI, pnpm's workspace state was polluted: catalog `vite: workspace:@voidzero-dev/vite-plus-core@*` resolved to literal `vite@7.99.0` in
the packed CLI manifest, and pnpm then failed at install time with
`ERR_PNPM_NO_MATCHING_VERSION` looking up vite@7.99.0 in the npm
registry.

Pack core (version bumped to 7.99.0, name unchanged) and the CLI
normally, then run a new `tool repack-vite-tgz` subcommand that reads
the core tgz, rewrites the inner `package.json#name` to "vite", and
writes a sibling `vite-7.99.0.tgz`. The repacked tgz still satisfies
bun's strict name+version peer check for vitest 4.1.5's `peer vite ^6 || ^7 || ^8`, but no workspace pollution occurs because we never modify the in-tree package name.

Pointing every package manager at the renamed vite-7.99.0.tgz worked
around bun's strict peer check but broke pnpm: when both a workspace
sub-package and the workspace override resolve to the same tgz that
advertises itself as vite@7.99.0, pnpm tries to validate the version
against the registry and aborts with ERR_PNPM_NO_MATCHING_VERSION.

Revert to the main-branch shape for pnpm/npm/yarn (same core tgz for
both `vite` and `@voidzero-dev/vite-plus-core` overrides) and keep the
renamed tgz only for bun, where vitest's `peer vite ^6 || ^7 || ^8`
demands a tgz whose package.json#name is "vite" and whose version is
in range. Stop bumping core/CLI to 7.99.0 entirely; pack at 0.0.0 and
post-process a sibling vite-7.99.0.tgz via `tool repack-vite-tgz`,
which now also strips the workspace's vite→vite-plus-core self-ref so
the alias tgz isn't circular.

The test-vp-create matrix picks the override target per package manager
via a new VITE_OVERRIDE_TGZ matrix env. ecosystem-ci/patch-project.ts
mirrors that logic for the bun-vite-template project only; every other
ecosystem project routes vite through the core tgz.

Apply formatting fixes flagged by `vp check`: oxfmt added braces around
single-line if-bodies in build.ts and reflowed the new repack-script
helper and ecosystem-ci patch ternary. No behavior change.

Restores deduping previously done by the bundled wrapper. Without this,
downstream projects co-resolve their own vitest with the one vp-cli ships,
causing undefined `describe` (dual runner state) and TS2769 type clashes.

Pinned to VITEST_VERSION (4.1.5) — the version vp-cli ships transitively.
ecosystem-ci/patch-project.ts mirrors the same overrides so the CI matrix
exercises the same dedup behavior production users get.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

User configs like `defineConfig({ test: { globals: true } })` were
failing tsc with TS2769 because vite-plus's defineConfig typed its
parameter as vite-plus-core's UserConfig, which doesn't get vitest's
`declare module 'vite'` augmentation (vite-plus-core is a fork).

Extend the local `declare module '@voidzero-dev/vite-plus-core'`
augmentation to add `test?: VitestInlineConfig`. New unit test
locks the behavior in.

@vitest/mocker's static hoister only recognizes 'vitest' as the
mock-API source string. User configs from migrated projects import
`vi` from 'vite-plus/test', which mocker doesn't see, so vi.mock()
fails at runtime with "problems in resolving the mocks API".

Inject a pre-stage Vite plugin into vite-plus's defineConfig
wrapper that rewrites bare `from 'vite-plus/test'` -> `from 'vitest'`
in user source. Subpaths are left alone. Override pinning (task #50)
guarantees both specifiers resolve to the same module so this is
runtime-safe.

This is a workaround until @vitest/mocker accepts a configurable
hoistedModule option upstream.

…itest/config

`export * from '@voidzero-dev/vite-plus-core'` and `export * from
'vitest/config'` both expose `mergeConfig` (and a handful of other
vite-from-vitest re-exports). Per the ES spec, two star-exports of
the same name make any named import fail with a SyntaxError --
breaking frm-stack and any other config that imports `mergeConfig`
from `vite-plus`.

Switch the vitest/config re-export to an explicit list of names
unique to vitest (configDefaults, coverageConfigDefaults, etc),
leaving the shared names (mergeConfig, loadConfigFromFile, ...) to
come from vite-plus-core only.

A one-off ECONNRESET on the pnpm registry got baked into
command-add-pnpm11-with-workspace/snap.txt, then never reproduced,
making the snap permanently diff against live runs. While fixing,
discovered the existing pnpm WARN redaction regexes contained U+2009
thin-space characters in their patterns, so they never matched real
pnpm output -- only test fixtures that also contained thin spaces.

Normalize all 4 WARN regexes to ASCII space, and broaden the
GET-registry pattern to drop transient network warnings like
`[WARN] GET ... error (ECONNRESET). Will retry ...` so single-run
flakes don't get baked into snapshots.

npmx.dev pins @vitest/coverage-v8@4.1.0 alongside vitest. Without
overriding coverage-v8 to match VITEST_VERSION (4.1.5), pnpm
installs two physical copies of @vitest/mocker on disk and vitest's
runtime mocks-API check (`vi` came from the same mocker copy as
the hoister registered) fails.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

@vitest/mocker's static hoister hardcodes `hoistedModule = 'vitest'`
and runs as part of vitest's own plugin pipeline that executes
before user plugins -- so the previously-shipped runtime plugin
(d69fe03) cannot intercept it for `vi.mock` calls.

Move the rewrite into the Rust migrator so source is fixed at
migrate-time and the mocker sees the canonical specifier. The
runtime plugin stays as a safety net for code authored after
migration.

Concretely:
- Drop the forward `'vitest'` -> `'vite-plus/test'` ast-grep rule
  (the bare-root specifier is now intentionally preserved).
- Add a reverse `'vite-plus/test'` -> `'vitest'` ast-grep rule that
  is anchored to the exact root specifier; subpaths such as
  `'vite-plus/test/browser-playwright'` are intentionally left
  untouched because they map to dedicated vite-plus shim exports.
- Mirror the same change for `/// <reference types=... />`
  triple-slash directives.
- Update existing tests to expect the new behaviour and add
  dedicated forward + negative coverage for the reverse rewrite.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Trivial fmt-only fix on two test fixtures introduced by 21937c5.

…rite

Commit 21937c5 swapped the Rust migrator's direction from
`'vitest' -> 'vite-plus/test'` (forward) to `'vite-plus/test' -> 'vitest'`
(reverse) to fix vinext's `vi.mock` hoister bug. But that broke
`vp create` because template-generated test files use `from "vitest"`
and the `test-vp-create.yml` CI workflow doesn't include the vitest
family in its `VP_OVERRIDE_PACKAGES` env — so `vitest` is not
installable in the generated project and `vp check` fails with
TS2307.

Restoring the forward rewrite means templates with `from "vitest"`
become `from "vite-plus/test"` (which IS resolvable via the vite-plus
dep). The `vi.mock` hoister bug for migrated projects returns, but
that's already documented as an upstream blocker (PR comment
4466063059) — the cure was worse than the disease.

Coverage-v8/coverage-istanbul overrides from 895e4db are kept.

Task #56 narrowed `export * from 'vitest/config'` to an explicit list,
but missed the vitest-specific type aliases (ViteUserConfig,
ViteUserConfigExport, TestProjectConfiguration, TestUserConfig, etc.).
Downstream like vue-mini imports `ViteUserConfig` from 'vite-plus' and
broke with TS2724.

Add the full set of vitest-only type exports. Runtime exports
(mergeConfig, defineConfig, loadConfigFromFile) still come from
vite-plus-core only to avoid star-export conflicts.

pnpm v10 changed the formatting of the `Packages: +<n>` summary
line (no longer indented). Update the captured snaps for
`command-list-pnpm10-with-workspace` and `command-outdated-pnpm10`
to match. Verified locally that subsequent runs produce no diff.

The mocker rewrite plugin was only injected into the root vite config,
so projects defined under `test.projects` (each spinning up an isolated
Vite pipeline) never got the rewrite — `vi.mock()` failed with
"problems in resolving the mocks API" for source that imports from
`'vite-plus/test'` inside a project.

Fix `vp check` formatting failures from a13027f.

TS infers the narrowed types after `typeof project === 'function'`
and `typeof project === 'object' && project !== null`, so the
explicit casts trip `typescript(no-unnecessary-type-assertion)`.

…l success

The initial install (pre-migration) is best-effort — migration
proceeds regardless of its outcome, and the final install (with
--force / --no-frozen-lockfile) is the authoritative recovery.
But `handleInstallResult` was being called on both summaries and
setting `process.exitCode` on either failure, so a successful
final install was being clobbered by a failed initial install's
exit code, making the migration look failed when it wasn't.

Add a `propagateExitCode` opt-out and apply it to the initial
call only. Both failures still get reported via `report.warnings`.

The env var replaces VITE_PLUS_OVERRIDE_PACKAGES entirely, so the
CI's previous map (which only listed vite + vite-plus-core) left
created projects with a catalog missing every vitest entry. Mirror
the vitest family from ecosystem-ci/patch-project.ts so installs
succeed.

- upgrade-deps.ts now bumps the @vitest/browser, @vitest/browser-playwright,
  @vitest/browser-preview, @vitest/browser-webdriverio catalog entries
  alongside the vitest line, and rewrites the VITEST_VERSION constant
  in packages/cli/src/utils/constants.ts.
- ecosystem-ci/patch-project.ts imports VITEST_VERSION from the CLI
  constants so the three places that previously hardcoded "4.1.5"
  collapse to a single source of truth (constants.ts).

`LEGACY_WRAPPER_FALLBACK_VERSIONS.vitest` was set to `^${VITEST_VERSION}`,
while fresh migrations write the exact `VITEST_VERSION` via
`VITE_PLUS_OVERRIDE_PACKAGES`. Projects cleaned up from a stale
`@voidzero-dev/vite-plus-test` alias should land on the same exact
pin as fresh migrations, not a caret range that allows unintended
drift on reinstall.